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(57) The optical amplrfier splitter arrangement is 
used in a tree-like optical network (APON) consisting of 
the cascade connection of dedicated branches, of the 
arrangement and of a common branch. The arrange- 
ment is coupled between a plurality of optical network 
users and an optical line terminator, via the dedicated 
branches and the common branch respectively. The 
network enables upstream transmission of information 
signals from the optical network users to the optical line 
terminator. The optical amplifier splitter arrangement 
includes for each branch of the dedicated branches : 

an optical amplrfier to amplify an information signal 
with a gain value and to thereby generate an ampli- 
fied information signal with a predetermined power 



level; 

an optical switch on/off coupled between the optical 
amplifier and an optical splitter to pass the amplified 
information signal when the information signal is 
present and to interrupt the branch when the infor- 
mation signal is not present. The optical splitter is 
included in the arrangement to combine all ampli- 
fied information signals according to a multiple 
access technique and to thereby generate an out- 
going optical signal for application to the optical line 
terminator. 
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ure will be obvious to a person skilled in the art. 

The optical amplifier splitter arrangement OAS is 
used m a tree-like optical network consisting of the cas- 
cade connection of dedicated branches B1. B2 

8i. . Bn and of the optical amplifier splitter arrangement 5 
OAS and of a common branch. The optical amplifier 
splitter arrangement OAS is coupled between a plurality 

of optical network users ONU1. ONU2 ONUi 

ONUn and an optical line terminator OLT via the above 
mentioned dedicated branches and common branch w 
respectively. 

The optical amplifier splitter arrangement OAS 
includes for each branch e.g. Bi, of the dedicated 
branches B1. B2 Bi Bn two basic parts : 

15 

an optical amplifier OAi coupled to the respective 
netwotk user ONUi of the optical network users 

ONU1. ONU2 ONUi ONUn; and 

an optical switch on/off SW ON/OFFi coupled 
between the optical amplifier OAi and an optical 20 
splitter OS. 

The optical splitter OS is coupled between all opti- 
cal switches on/off SW ON/OFF1, SW ON/OFF2 

SW ON/OFFi SW ON/OFFn which are simular to the 25 

optical switch on/off SW ON/OFFi and the optical line 
terminator OLT 

The optical amplifier splitter arrangement OAS ena- 
bles upstream transmission in the optical network of 

information signals INI , IN2, .... INi INn from the 3C 

optical network users ONU1. ONU2 ONUi, .... 

ONUn to the optical line terminator OLT 

The principle working of the optical amplifier splitter 
OAS will be explained in the following paragraph with 
respect to a signal INi transmitted over a branch Bi. the 35 
working with respect to the other branches being identi- 
cal. 

The optical amplifier OAi amplifies INi with a gain 
value Gi (not shown) and generates thereby an ampli- 
fied information signal A-INi with a predetermined 4C 
power level. 

The optical switch on/off SW ON/OFFi passes the 
amplified information signal A-INi when it is present, but 
interrupts the branch Bi when the amplified information 
signal A-INi is not present. 4 $ 

The optical splitter OS combines all amplified infor- 
mation signals A-INI. A-1N2 A-INi A-INn simular 

to the amplified information signal A-INi according to a 
multiple access technique and generates thereby an 
outgoing optical signal OUT for application to the optical so 
line terminator OLT 

In this embodiment the working of the optical ampli- 
fier OAi and the optical switch on/off SW ON/OFFi of 
each branch Bi is controllec by means of control means 
CTRLi. The control means CTRLi is coupled to the OAi 55 
and the optical switch orVcff SW ON/OFFi and controls 

the gain value Gi by means of a first electrical con- 
trol signal CTRL- ATcomposed of gain setting "dataH ~ 



GSi (not shown) and gain tuning data GTi (not 
shown); and 

the switch on/off SW ON/OFFi by means of a sec- 
ond electrical control signal CTRL-Bi. 

The gain setting data GSi. the gain tuning data GTi 
and the second electrical control signal CTRL-Bi can be 
determined in different ways. A few particular imple- 
mentations to determine them are described in a func- 
tional way in the following paragraphs, but they are not 
shown in the figure to avoid overloading thereof. 

To determine the second electrical control signal 
CTRL-Bi. for each branch Bi. the control means CTRLi 
further includes power detection means which via an 
optical tap draws off the information signal INi a small 
power part. The power detection means determines 
whether the information signal INi is present or is not 
present and determines the second electrical control 
signal CTRL-Bi as a result thereof. 

To determine the gain setting data GSi. for each 
branch Bi t the control means CTRLi further includes 
power measuring means. The same optical tap as 
above is used and the power measuring means meas- 
ures the power of the information signal INi and deter- 
mines the gain setting data GSi based thereon. 

It has to be noted here, that to ensure that the 
power measuring means has enough time to fulfil its 
function, an optical delay line (not shown) is coupled 
between the optical tap and the optical amplifier OAi. 
The optical delay line delays the information signal INi 
untitl the optical amplifier OAi is adjusted. 

To determine the gain tuning data GTi, for each 
branch Bi. the control means CTRLi further includes 
additional power measuring means. Via an additional 
optical tap. coupled between the optical switch on/off 
SW ON/OFFi and the optical splitter OS a small power 
part is drawn off the amplified information signal A-INi 
and the additional power measuring means measures 
the power of the amplified information signal A-INi and 
determines the gain tuning data GTi based thereon. 

Furthermore it is noted that although for the optical 
amplifier OAi an erbium doped fibre amplifier is used, 
semiconductor optical amplifiers are very good candi- 
dates to use in this implementation because of their low 
switch-on time. It is also remarked that these semicon- 
ductor optical amplifiers can be used to integrate the 
functions of the optical amplifier OAi and of the optical 
switch on/off SW ON/OFFi. 

An alternative implementation to determine the 
second electrical control signal CTRL-Bi is realised for 
optical networks where the optical splitter OS combines 

the amplified information signals A-1N1 . A-IN2 A-INi, 

A-INn according to a time division multiple access 

technique. For such an optical network, the optical 
amplifier splitter arrangement OAS includes an optical 
network terminator NTOAM (not shown) for performing 
operation and maintenance functions. The NTOAM is 
coupled to the optical line terminator OLT by means of — 
also an additional optical tap? and fdlhe contrormeans~~" 
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fGi) by means of a first electrical control signal 
(CTRL-Ai) composed of gain setting data (GSi) and 
gam tuning data (GTi). and to control said switch 
on/off (SW ON/OFFi) by means cf a second electri- 
cal control signal (CTRL-Bi). 5 

3. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in, that for each 
said branch (Bi). said control means (CTRLi) fur- 
ther includes power detection means provided to 10 
detect whether said one information signal (INi) is 
present or is not present and to determine said sec- 
ond electrical control signal (CTRL-Bi) as a result 
thereof. 

75 

4. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in that said opti- 
cal splitter (OS) is provided to combine said ampli- 
fied information signals (A-IN1, A-IN2 A-INi 

A-INn) according to a time division multiple access 20 
(TDMA) technique, and in that said arrangement 
(OAS) also includes an optical network terminator 
(NTOAM) for performing operation and mainte- 
nance functions and which is coupled to said optical 
line terminator (OLT) and said control means 25 
(CTRLi), said optical network terminator (NTOAM) 
being included to capture special grant information 

out of downstream signals sent from said optical 
line terminator (OLT) to said optical network users 

(ONU1, ONU2 ONUi ONUn) and to apply 30 

said special grant information to said control means 
(CTRLi) to thereby enable said control means 
(CTRLi) to determine whether said information sig- 
nal (INi) will be present or not present within a pre- 
determined time interval and to determine said 35 
second electrical control signal (CTRL-Bi) as a 
result thereof. 

5. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in that for each 40 
said branch (Bi) said control means (CTRLi) further 
includes power measuring means provided to 
measure the power of said one information signal 
(INi) and to determine said gain setting data (GSi) 
based thereon. 4 s 

6. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in that, for each 
said branch (Bi). said control means (CTRLi) fur- 
ther includes power measuring means provided to sc 
measure the power of said amplified information 
signal (A-INi) and to determine said gain tuning 
data (GTi) based thereon. 



7. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in that, for each 
said branch (Bi). said control means (CTRLi) fur- 
ther includes. power measuring means provided to 
measure the power of said amplified information 



55 



signal (A-INi) and to provide a value of measured 
power of said amplified information signal (A- INi) 
and further includes memory means to memorize 
said value, said value being used to determine said 
gain tuning data (GTi) for a following transmitted 
information signal (INi). 

8. Optical amplifier splitter arrangement (OAS) 
according to claim 2 characterized in that said 
arrangement (OAS) also includes a power level unit 
(P-opt) coupled between a control output of said 
optical splitter (OS) and said control means (CTRLi) 
associated with each branch (Bi), said power level 
unit being (P-opt) provided to measure the power 
level of said outgoing optical signal (OUT) and to 
supply as a result thereof electrical power level data 
(P-OUT) to said control means (CTRLi) to thereby 
enable said control means (CTRLi) to determine 
said gain tuning data (GTi) when said information 
signal (A-INi) is present. 

9. Optical amplifier splitter arrangement (OAS) 
according to claim 1 characterized in that said opti- 
cal splitter (OS) and all optical switches on/off (SW 

ON/OFF1, SW ON/OFF2 SW ON/OFFi SW 

ON/OFFn) simular to said optical switch on/off (SW 
ON/OFFi) are integrated in an optical switch 
(OSW). 

10. A method used in a tree-like optical network 
(APON) to perform upstream transmission of infor- 
mation signals (INi, IN2 INi INn) from a plu- 
rality of optical network users (ONUi, ONU2 

ONUi ONUn) to an optical line terminator (OLT) 

via dedicated branches (B1 . B2 Bi Bn) and a 

common branch respectively, characterized in that 
said method for each one (INi) of said information 

signals (INI . IN2 INi INn) comprises the 

steps of : 

a. amplifying said information signal (INi) and 
thereby generating an amplified information 
signal (A-INi); 

b. passing said amplified information signal (A- 
INi) when said information signal (INi) is 
present and interrupting said branch (Bi) when 
said information signal (INi) is not present; 

and further includes the step of : 

c. combining all amplified information signals 

(A-IN1. A-IN2 A-INi A-INn) simular to 

said amplified information signal (A-INi) 
according to a multiple access technique 
thereby generating an outgoing optical signal 
(OUT) which is transmitted to said optical line 
terminator (OLT). 
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2. Discussion 

In the broadband access network specified by FSAN, the OLT manages and controls network terminations such as 
ONT and NT, i.e., it manages their configuration, faults, performance, and security. It is useful to standardize the 
interface between the OLT and the ONT/NT while taking into account the following three viewpoints. 

(1) ONT/NT Management and Control Channel (OMCC) 

A point-to-point ATM VP connection between the OLT and each ONT/NT serves as the OMCC. 

(2) ONT/NT Management and Control Protocol 

As simple a protocol as possible is the goal. The Simple Device Protocol (SDP), which uses one-cell long 
messages , has been proposed and discussed in the ATM Forum. This document proposes to adapt this protocol for 
the system specified in ITU-T Rec. G.983. 

(3) ONT/NT Management and Control Information Model 

This document proposes to adapt a simplified protocol-independent MTB (Management Information Base) 
that has as much commonality with other ITU-T Recommendations as possible. This makes the ONT/NT 
Management and Control Interface simple while maintaining commonality with the MIB for the Q3 interface between 
the network-element manager and the OLT. 



3. Proposal 

The proposed ONT/NT Management and Control Interface Specification is attached as Annex A. A list of contents of 
the Recommendation shows the study items. Proposals for Sections 1, 2, 3, 8 and 9. 1 are included in this contribution; 
the missing parts require further study and will be provided in a delayed contribution at the next meeting. 

Further contributions are welcomed to accelerate the discussions. 
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1. Scope of This Document 
/. 1 Introduction 

This document specifies the ONT/NT Management and Control Interface (OMCI) to enable multi-vendor 
interoperability between the OLT and the ONT/NT. 

The OMCI specification described in this document consists of the following three parts: 

1. The ONT/NT Management and Control Management Information Base (MEB); 

2. The ONT/NT Management and Control Channel (OMCC); 

3. The ONT/NT Management and Control protocol and detailed messages. 

L2 OMCI in the ITU-T Rec. G.983 System 

Note that the terminology used in this document is not always the same as the terminology used by the broad-range 
ITU-T Rec. G.983 documents. Table 1 is provided to assist the reader in understanding the mapping between these 
terms. 



Table 1: Mapping of Equivalent Terms 



Commonly Used Equivalent 


Term used in this document 


ONU in the FTTH configuration 


ONT 


ONU in the FTTB, FTTC and FTTCab configurations 


ONU 


NT in the FTTB, FTTC and FTTCab configurations 


NT 



The OMCI specification fits into the overall ITU-T Rec. G.983 model for an access network system as illustrated in 
Figure 1. 



B-UNI 



V- interface 




Physical link (Fiber or Copper) 
ONT/NT management and control interface 



Figure 1 Reference configuration 



1.2.1 ONU 

The ONU functions are: 
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(1) Access network line termination function (AN-LT) 

This function terminates the access network line, i.e., the PON interface 

(2) Access network repeater line termination function (ANR-LT) 

This function terminates the access network repeater line, e.g., . an xDSL interface. 

(3) ATM multiplexer and demultiplexer function (ATM-Mux) 

This function provides ATM connections between the AN-LT and the ANR-LTs. 



Figure 2 ONU functional diagram 

ONU 



ANR-LT 



ATM-MUX 



ANRI 








ANRI 




ANR-LT 















AN-LT 



ANI 



1,2.2 ONT 

The ONT functions are: 

(1) Access network line tennination function (AN-LT) 

This function terminates the access network line, i.e., the PON interface 

(2) User network interface line termination function (UNI-LT) 

This function terminates the user/network interface line. 

(3) ATM multiplexer and demultiplexer function (ATM-Mux) 

This function provides ATM connections between the AN-LT and the UNI-LTs. 



ONT 



UNI 



UNI 



UN1-LT ATM-MUX 

AN-LT 



UNI-LT 



ANI 



Figure 3 ONT functional diagram 



1.2.3 NT 
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The NT functions are : 

(1) Access network repeater line termination function (ANR-LT) 

This function terminates the access network repeater line, e..g., an xDSL interface. 

(2) User/network interface line termination function (UNI-LT) 

This function terminates the user/network interface line. 

(3) ATM multiplexer and demultiplexer function (ATM-Mux) 

This function provides ATM connections between ANR-LT and UNI-LTs. 



NT 



UNI 



UNI 



UNI-LT 



ATM-MUX 

ANRI-LT 



UNI-LT 



ANRI 



Figure 4 NT functional diagram 



1.2.4 ONT vs. ONU 

The ONU is a complex network element, requiring some intelligence to execute the functions it supports (different 
operators may prescribe different functions). 

While the interface between the ONU and the OLT in Figure 1 looks similar to the one between the ONT and the 
OLT, one has to recognize that the ONU, by definition, is more complex than the ONT and implements more 
functionalities. Even though the physical layers of the PON interfaces for the ONU and ONT are functionally identical 
up to and including the ranging procedure, their management interfaces are different. Because of this, the definition 
of the ONU/OLT management interface requires more work and is not addressed in this document. 



1.2.5 ONT vs. NT 

The ONT and NT have the same UNI interface requirements. They have the same requirements regarding security, 
traffic priorities, reliability and other features. They only differ in physical layer functions towards the access 
distribution network. 

The ONT and NT are logical peripherals of the OLT and the ONU, respectively. Most of ONT/NT intelligence 
depends on OLT/ONU. Hence it makes sense to follow a common approach for their management. 

The ONT/NT management interface should be defined to allow vendors to offer modular, incremental capabilities to 
meet different levels of customer needs. This specification first targets low-cost ONT/NTs. It defines the simplest 
protocol necessary to support capabilities identified by the ITU-T Rec. G.983 as important for early deployment and 
interoperability, yet allows for optional components and future extensions. 
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1.2.6 VP-MUX Only ONT/NT 

Note that the ITU-T Rec. G.983 ATM-PON system as a whole (OLT and ONT/NT) can function as an ATM cross- 
connect with both provisioned and on-demand connectivity. The configuration of the ATM cross-connect can be 
initiated independently by 

1. The network element operations system via the management interface (e.g. Q3), or 

2. The Service Node (SN) over a VB5.2 Broadband Bearer Connection Control (B-BCC) signaling. 

The ONT/NT, however, always acts as a provisioned ATM multiplexer. The OMCI itself does not distinguish 
between these two cases except that in the on-demand case a fast reaction time of the OMCI is required. 

Also note that even though the ITU-T Rec. G.983 system as a whole (OLT and ONT/NT) can function as a VP as 
well as a VC switch, the low-cost ONT/NT addressed in this specification multiplexes/demultiplexes ATM 
connections on the VP level only, i.e.. only VPI translation is supported in the ONT/NT. 



2. Requirements of the management interface specification 

The OMCI uses a general-purpose protocol to control an ONT/NT and allows the OLT to: 

1 . Establish and release connections across the ONT/NT; 

2. Manage the UNIs at the ONT/NT; 

3. Request configuration information and performance statistics; 

4. Autonomously inform the system operator of events such as link failures. 

The OMCI protocol runs across an ATM connection between the OLT controller to the ONT/NT controller that is 
established at ONT/NT initialization. The OMCI protocol is asymmetric: the controller in the OLT is the master, and 
the one in the ONT/NT is the slave. Multiple ONTs may be controlled by a single OLT controller using multiple 
instantiations of the protocol over separate control channels. 

The ONT/NT management and control interface requirements given in this document are needed to manage the 
ONT/NT in the following areas: 

1. Configuration; 

2. Fault; 

3. Performance, and 

4. Security. 

2.1 Configuration management 

Configuration management provides functions to exercise control over, identify, collect data from and provide data to 
the ONT/NT. This involves the following: 

1 . Configuration of the equipment 

2. Configuration of the UNIs 

3 . Configuration of the ATM VP Link Termination Points and Cross-Connections 

4. Configuration of interworking VCC terminations (non-ATM UNIs only) 

5. Configuration of the OAM Flows 

6. Configuration of the physical ports 
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2.2 Fault management 

The ONT/NT suppors limited fault management only. Most of the operations are limited to failure indication. 
The managed entities in sections O-Error! Reference source not found, that are required to support the following 
failure-reporting functions: 

1. ONT/NT 

2. UNI cards 

3. Physical Path Termination Points 

4. TC Adaptors 

5. Interworking VCC Termination Points 

6. Software 

7. VPL Termination Points. 

An alarm table, based on related standards specified by ITU-T, ATMF, etc., is defined for each of these entities. 
The ONT informs the OLT of alarm status changes by sending alarm status change notifications. Note that these 
notifications are sent in unacknowledged messages which carry sequence numbers for the OLT to detect lost messages, 
see the next paragraph. 

Each alarm message carries an 8-bit sequence number that is incremented with each message modulo 255. When the 
OLT detects a gap in the received sequence, it asks the ONT/NT for an alarm status report by sending an alarm status 
reading command. Obviously, this command is acknowledged by a response that contains the alarm status. The OLT 
compares the received report with the copy of the alarm status for that ONT/NT in its memory and informs the 
network element manager of any differences between the two. 

The following code is used for alarm on/off: 



Coding 


Contents 


Description 


0 


off 


alarm is not active 


1 


on 


alarm is active 



The ONT/NT shall also support selective OAM cell loop-back testing at the UNI. The ONT/NT diagnostics is 
limited to ONT/NT self test. The OLT or element manager will process the information from the ONT/NT, for 
example, the OLT/EM will determine the severity of each alarm when reporting it to the network operator. 



2.3 Performance management 

The ONT/NT has only limited performance monitoring. Most of the performance monitoring is limited to PMD and 
TC layer performance monitoring. ATM cell level protocol monitoring, traffic management, and UPC/NPC 
disagreement monitoring are optional. 

2. 4 Security Management 
For further study 

3. Protocol-Independent MIB for the OMCI 

A protocol-independent MIB is used to describe the exchange of information across the OMCI. This logical MIB is 
based on the ATMF M4 Interface Requirements and Logical MIB. It is intended to form the basis from which 
protocol-specific models (e.g., simple device protocol for ONT/NT) are defined. Protocol-specific MTB 
implementations should resemble the protocol-independent MTB as much as practical. The protocol-independent MIB 
should not, however, place unnecessary constraints on its protocol-specific implementations. 
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The protocol-independent NOB presented in this document has been defined in terms of managed entities. The 
managed entities are abstract representations of resources and services in an ONT/NT. The managed entities defined 
in the ATMF M4 MOB that relate to ONT/NT management are listed in Table 2. 



Table 2: Managed Entities 



Managed entities 


Relation to ONT/NT 


AAL Profile 


T IcpH fnr non-ATM T RvTTq 


AN1 


KJis l /in i neiworK-sicic iiner idee 


ATM Cell Protocol Monitoring Current Data 




ATM Cell Protocol Monitoring History Data 


(optional) 


ATM Cross Connection 


A 1 Ivl V r IVIUX 


ATM NE 


UN 1/N 1 


Equipment 




Equipment Holder 


UNI card slot 


Interworking VCC Termination Point 


T7or nnn-ATM T fWTc 
rur iiuii rt. i iva u rN is 


Multipoint Bridge 


(optional)) 


Physical Path Termination Point 


TfMT-T T AXJ-T T 


Plug-in Unit 


uini cam 


Software 


sorxware in diiu uini uuuj 


TC Adaptor 


TV* lotmr r\r\ KrttV* T TKTT-T T onH AM.! T 

l \^ layer on doui u in i -l, i dim rviN-i_> i 


TC Adaptor Protocol Monitoring Current Data 


(optional) 


TC Adaptor Protocol Monitoring History Data 


(optional) 


UNI 


User/network interface 


VPL Termination Point 


VP link termination for VP Mux 


CES Service Profile 


For CES service 


EP Service Profile 


For EP service 


AAL Protocol Current Data 


(optional) 


AAL Protocol History Data 


(optional) 


UPC/NPC Disagreement Monitoring Current Data 


(optional) 


UPC/NPC Disagreement Monitoring History Data 


(optional) 


VP OAM flow profile 


(optional) 



3. 1 Managed Entities Relation Diagrams 

The relationships between the supported managed entities are summarized in Figures 5-8. 



ITU-TVCOM-IACOM 1 5\C\ 1 09E. DOC 



12.08.98 



12.08.98 




COM 15-109-E 



ATM NE 



Multipoint 

Bridge 
O-Q" 



TC Adaptor 



ATM Cross 
Connection 



D C 



VPLTP 



Legend: 



: Managed Entity 
: Zero or More 
: Zero or One 
: Association 



A B : A Contains B 




UPC/NPC 
Disagreement 

Monitoring 
Current Data 



UPC/NPC 
Disagreement 

Monitoring 
History Data 



C VPCTP 



Interworking VCC TP 



Non-ATM UNI 



Figure 5 Managed Entity Relation Diagram (1 of 4) 
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ATM NE 



Equipment 




Equipment 
Holder 



Plug-In ^* 
Unit 



Physical 
Path 
, Termination 
Point 



Legend: 



Managed Entity 

: Zero or More 

: Zero or One 
: Association 
: A Contains B 



Figure 6 Managed Entity Relation Diagram (2 of 4) 
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Legend: 



Managed Entity 



• ; Zero or More 

O ; Zero or One 

; Association 

A^- B : A Contains B 



Physical 




TC 


Path 




Adaptor 


Termination 






Point 







Figure 7 Managed Entity Relation Diagram (3 of 4) 



[P service profile 




CES Service Profile 



AAL1 Protocol 
Current Data 



AAL1 Protocol 
History Data 



ATM NE 
* 



InterworkJng VCC 
Termination Point 



AAL3/4 Protocol 
Current Data 



AAL3/4 Protocol 
History Data 



AAL5 Protocol 
Current Data 



AAL5 Protocol 
History Data 




AAL1 Profile 



AAL3/4 Profile 



AAL5 Profile 



Legend: 



N 

| | : Managed Entity * 



-• : Zero or More 
-O : Zero or One 
— : Association 



: A Contains B 



Figure 8 Managed Entity Relation Diagram (4 of 4) 
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3.1.1 ONT/NT Specific Management Entity Relations Diagram 

Figure 9, derived from Figures 5, 6 and 7, shows the ONT/NT management entity relations. Note as an example that 
only ONT/NT with ATM UNIs is considered here. Within each ONT/NT there is an ANI and a fixed maximum 
number (1 ...NmaxpUNI) of UNIs that either reside on a fixed maximum number (O..NmaxUNIcard ) of UNI cards or 
are integrated into the ONT/NT. Each UNI is associated with a tcAdaptor instance that models the adaptation of the 
ATM layer to the physical layer. Each instance will be associated with a fixed maximum number (1 ...NmaxVPL) of 
VPL Termination Point instances modelling VP link terminations. A fixed maximum number of VP-Cross 
connection instances (1 ...Nmax-atmVPMux) will be available for modelling VP-Cross connections. 
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ONT/NT Management 
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Protocol 
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Data 



: TC Adaptor 
• PM Current 
-O Data 



VPL TP 



TC Adaptor 
PM History 
Data 



Legend: 



UPONPC 
Disagreement 
Monitoring 
Current Data 



I 



: Supported 
Managed Entity 

: Optional 
Managed Entity 



• : Zero or More 
O t Zero or One 
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UPONPC 
Disagreement 
Monitoring 
History Data 



Figure 9: ONT/NT management entity relation diagram 

A detailed description of the ONT/NT managed entity is provided in the sections that follow. These sections describe 
the purpose and attributes of each entity and are organized as follows: 
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1 . ONT/NT equipment management 

2. AN (i.e. PON/xDSL) interface management 

3. UNI management 

4. VP layer management 



4. ONT/NT Equipment Management 



5. ANI Management 



6. UNI Management 



7. VP MUX Management 

8. ONT/NT Management and Control Channel (OMCC) 

An ATM connection shall be provisioned for the OMCC. ITU-T Rec. G.983 specifies a PLOAM message that 
activates a VPI/VCI pair between the OLT and ONT processors. The VPI/VCI value for the management channel of 
each ONT is programmed by the OLT using this message. The OMCCs of different ONTs should be assigned 
different VPIs. 

The xDSL NT uses the default value VPI=1, VCI=32, and therefore needs no provisioning, since the NT-to-ONU 
connection is a point-to-point link. 

It is outside the scope of this document to specify how NT management information is transferred to the OLT and then 
to the AN management system. There are two typical options: either the NT management VP is not terminated in the 
ONU but routed to the OLT, or the ONU terminates the NT management VP, processes the management information 
from the different NTs and provides the OLT with filtered information. Several factors determine which alternative is 
the best fit for a given ONU. Examples of such factors are cost, security, traffic volume, ATM class of service and 
reliability. 

The following performance requirements related to the OMCC should be studied further with input from operators: 

1. The cells carrying ONT management messages should be sent with cell loss priority CLP = 0. 

2. The total traffic on all the OMCCs should not exceed x (TBD) percent of the PON bandwidth. 

3. The QOS parameters of the ATM connection used for the OMCC. 

4. Message Response Time: The system should support Response Times that do not exceed x (TBD) seconds for 
95% of the messages. 
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9. ONT/NT Management and Control Protocol 

9. 1 ONT/NT Management and Control Protocol Cell Format 

9.1.1 Introduction 

Each ONT/NT Management and Control Protocol packet is encapsulated directly in a single 53-byte ATM cell. It 
complies with the ATMF Simple Device Protocol (SDP) format, see Figure 8. The following subsections discuss the 
details. 



ATM header 
(5 bytes) 


Transaction 
Correlation 
ID 

(2 bytes) 


Message 

Type 

(lbyte) 


Device 
ID 

Type 
(1 byte) 


Message 
Identifier 
(3 bytes) 


Message contents, 
(33 bytes) 


AAL.5 
trailer 
(8 bytes) 






4 _ » 





Defined by FSAN 
Figure 8 ONT/NT Management and Control Protocol cell format 



9.1.2 ATM Header: 

The header contains the VPI/VCI value of the OMCC for the addressed ONT/NT, see Section 0. 

9.1.3 Transaction Correlation ID (SDP compliant): 

Used to associate a request message with its response message. For request messages, the OLT selects any transaction 
identifier. A response message carries the transaction identifier of the message to which it is responding. The 
transaction identifier of event messages is zero. 

The mechanism which the OLT uses to assign the Transaction Correlation ID in an acknowledged command is not 
standardized and is left to the implementer. 

However, since the Transaction Correlation ID is used to match a command from the OLT to the ONT with a 
response from the ONT to the OLT, some care is required in the choice of the Transaction Correlation ID. 
The OLT must assign the Transaction Correlation IDs in such a way that whenever it sends a command with 
a Transaction Correlation ID which has been used before in another command to the same ONT, it is 
guaranteed with sufficiently high probability that no response for the first command can be received 
anymore. 



9.1.4 Message Type 

The message type field is sub-divided into four parts: 



g 


7 


6 5 




1 


DB 


i AR 


ak ; 


MT 





Figure 9 Message type field subdivision 
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The most significant bit, bit 8, is reserved for the destination bit (DB). This bit is defined in SDP for source routing. 
In the OMCI this bit is always 0. 

Bit 7, Acknowledge Request (AR), is used to indicate whether or not the message requires an acknowledgment. 

— 1 : acknowledgment expected 

— 0: acknowledgment is not expected 

Note that "acknowledgment" here is a response to an action request; it is not at the link layer. 
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Bit 6, Acknowledgment (AX), is used to indicate whether the message is an acknowledgment. 

— I : acknowledgment 

— 0: not an acknowledgment 

Bits 5 through I, Message Type (MT), are used to indicate the message type. Codes 0 to 3 are reserved by the ATMF 
SDP specification. Codes 4 to 3 1 are used by this specification. Table 3 lists the message types that are defined. 



Table 3. OMCI message types 



Type 


Purpose 


Acknowledgment 
expected 


MT value 


Create 


Create a managed entity instance with all its attributes 


yes 


16 


Delete 


Delete a managed entity instance 


yes 


17 


Set 


Set one or more attributes of a managed entity 


yes 


18 


Get 


Get one or more attributes from a managed entity 


yes 


19 


Notify of an 
attribute value 
change 


Notification of an autonomous attribute value change 


no 


20 


Alarm 


Notification of an alarm 


no 


Z 1 


get Alarm 


get Alarm Status 


yes 


22 


Test 


Request a test on a specific managed entity 


yes 


23 


Software 

download 

start 


Start a software download action 


yes 


24 


Software 
download 


Download a section of a software image 


yes 


25 


Software 
download end 


End of software download 


yes 


26 








RESERVED 


27 through 
30 


Null 


Used for data link acknowledgments 


no 


31 



9.1.5 Device ID Type 

The ITU-T Rec. G.983 OMCI protocol is identified by OxOA in this field. Other device ID types are specified by the 
ATM Forum . 

9.1.6 Message Identifier: 

The message identifier field is 3-byte long and divided into three parts, see Figure 10. 



Managed entity 
class identifier 



Managed entity instance 
identifier (MSB) 



: Managed entity instance 
: identifier (LSB) 



Figure 10 Subdivision of the message identifier field 

The most significant byte of the message identifier field is used to indicate which managed entity class is the target of 
the action specified in the message. The maximum number of possible managed entity classes is thus 256. The least- 
significant two bytes of this message identifier field are used to identify the managed entity instance. The maximum 
number of instances per managed entity class is thus 65,536. 
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9.1.7 Managed entity class identifier 



Table 4: Managed entity classes in the OMCI 



Managed entity class 


Message identifier value 


ONT/NT 


1 


UNI Card Holder 


2 


UNI Card 


3 


Software Image 


4 


UNI 


5 


TC Adapter 


6 


Physical Path Termination Point 


7 


Interworking VPC Termination Point 


8 


AAL1 Profile 


9 


AAL2 Profile 


10 


AAL3/4 Profile 


11 


AAL5 Profile 


12 


CES Service Profile 


13 


IP Service Profile 


14 


VPL Termination Point 


15 


VP Cross Connection 


16 


QoS Descriptor 


17 


Priority Queue Profile 


18 


Operator Specific 


19 


Vendor Specific 


20 



9.1.8 Managed entity instance identifier 

Depending on the managed entity, there will be only one (e.g. ONT/NT) or several (e.g. VPL Termination Point) 
instances. Each instance is identified by its ID number. 

9.1.9 Message Contents 

The layout of the message content field is message specific. The detailed layouts of all the messages are given in 
Section 0. 

9.1.10 AAL5-Trailer 

The eight bytes of this field are used as follows: 



1. 

2. 
3. 
4. 



The CSCS-User-to-User-Indication (CPCS-UU) field is set to all 0s at the transmitter and ignored at the receiver. 

The CPCS Common Part Indication (CPCS-CPI) field is set to all 0s at the transmitter and ignored at the receiver. 
The length of the CPCS-SDU field is set to 0x0028 (40 decimal). 
32-CRC (4 bytes) as specified in ITU-T 1.363. 
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10. Messages 

11. MEB Synchronization 

12. Scenarios 

12. 1 ONT/NT Configuration Scenario 

12.2 UNI Card and UNI Configuration Scenario 

12.2.1 UNI Card Provision and De-provision 

12.2.2 UNI Card Insertion 

12.2.3 UNI Card Removal 

12.2.4 Recovery on UNI Card re-insertion 

12. 3 VP Cross-connection Scenario 

12.3.1 VP Cross-connection set-up 

12.3.2 VP Cross-connection deletion 

12.3.3 VP Termination Point deletion 

12. 4 Software Download 
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